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ANNOUNCED SESSION CONTROL 



The present invention relates to the announcement and subsequent management of media 
stream comiections for a media session over a communications network. 

Multicast transmissions are becoming iricreasingly common on the Internet. In contrast to 
standard Internet Protocol (IP) point to point transmissions (unicast), IP multicast allows 
the simultaneous transmission of information to a group of recipients from a single source. 
Routing support for IP multicast transmissions is provided by the MBone (IP Multicast 
Backbone) which is a virtual network layered on top of the Internet. 

IP multicast allows real-time communications over wide area IP networks and typical 
transmissions include video and audio conferencing, live multimedia training, university 
lectures and transmission of live television programmes. 

A multicast transmission usually consists of a multimedia session made up of several 
individual media streams typically carrying video, audio, whiteboard or raw dau. Some 
sessions are persistent, but the majority exist for a specific period of time, although need 
not be continuous. Multicast based transmissions on the MBone differ from unicast IP 
transmissions in that any user receiving the transmission can join the session (unless the 
transmission is encrypted) and to receive a transmission, a user need only know the 
appropriate transmission address and timing information. 

An example of an IP multicast transmission system is described with reference to Figure 1. 



Prior to a multicast transmission, an appropriate announcement containing a session 
description is made, thereby allowing end users llOa-llOe to elect to receive the 
transmission. Each end user electing to receive the transmission is linked to a group IP 
Multicast address 120 associated with the transmission. At the transmission time of the 
multicast session, the session streams are transmitted from a source 130, or a plurality of 
sources, to the group address. At the group address, the transmission is disseminated along 
the links 140 to those end users who have elected to receive it (in this example end users 
llOa-llOc). 

An example of a conventional announcement and election system currently used is 
described with reference to Figure 2. Most public multicast sessions are announced at a 
single group IP multicast address 200 dedicated to the transmission of announcements to 
multicast end users. End users 210a-210e electing to receive the announcements are linked 
to the announcement group address and, in the same way as an actual session transmission, 
each announcement arriving at the announcement group address is disseminated to the end 
users. A front end interface 220 on each end user's computer displays information obtained 
from the associated session description for each announcement. The minimum information 
a session description must contain is a time and date that the session will be active and the 
group IP multicast address(es) from which the end user may elect to receive one or more 
media streams and to which they could send their own streams for the session. Using the 
front end interface, an end user can select the announced session(s), or their component 
stream(s) they wish to participate in and the interface then sets up the necessary links to the 
one or more group IP multicast addresses through an associated multicast multimedia 



application. 

„cino a Session Description Protocol (SDP), as 
Standard session descriptions are generated using a bession u 

.enned in the Internet Engineering Tas. Force's draft RFC 2327. SDP is a sitnple ASCII 
.ext based protocol that is used to describe real time multimedia sessions- and their related 
„g information. SDP messages are wrapped in a carrier protocol, .own as a 
session Announcement Protocol (SAP), which, in addition to containing the necessary IP 
addressing and routing information for transmission across the Internet or MBone, allows 
SDP message to be encrypted, signed or compressed, .n announcement can then be 
, sent at regular intervals to the announcement group address. As an alternative to SAP, a 

. u , • „ ,n SDP message on a World Wide Web site (WWW) 
session may be announced by placmg an SDP message 

•1 «r a unicast transmission inviting them to 
or by sending it to individuals by email or as a unicasi 

participate. 

■ , ,hnut each media stream in the multicast multimedia 

1 5 An SDP message conveys mformatton about each meo 

. ■ i„ th<. session A typical SDP message will 
session to allow the recipients to parttcpate m the session. A yp 

,.,„de the session name and purpose, the time(s, and date(s, s^sion will he active, the 
component media .reams of the session and information re,uired to participate in each 

a„ htclude deuils or the session's handwidth re,uirements. an encryption Icey necessary to 
par^cipate in a secure multicast transmission ushtg puhlic Icey encryption, contact 

<UKI, pointing to a WWW or an Intrant weh site where .Urther ir^ormation on the session 



may be found. 



The level of participation a user may make in a session or stream depends on its purpose. 
,n a mumcas. television session, typically users would only be able to receive the session 
streams whilst in a multicast conference session the communication would be bi-directional 
with a central server (such as group address 120) receiving each participants transmissions 
and relaying them to the other participants. The level of participation expected of a user in 
a session or stream may be explicitly stated in the session description or it may be inherent 
from the session description, for example when a receive-only applicaUon is associated 
with a media stream type in the session description. 

A common front end interface used by multicast erd users is known as Session Directory 
Rendezvous (SDR). This interface takes the received announcements, decodes the SDP 
message and displays the names of those sessions that are still current in a list. The end 
user may then select one of the listed am>ouncemen.s to view fitrther technical and user- 
oriented details of the announced session. From the displayed infortnation, the end user 
can then select to join individual streams of the session or to join the entire session. Once 
the streams to be joined are. selected, SDR starts the necessary multicast-enabled 
multimedia application on the end user's computer, such as Vic and Vat. and passes the 

«^ «r^rt !ifirirp<?s^ from the announcement onto the 
) relevant stream information (a transport port address) irom mc 

application allowing the application to establish the link to the associated IP multicast 
address and participate in the stream at transmission time. Having initiated the applications 
SDR plays no further part in the session. 



Recent increased usage and demand for (multi)media sessions has highlighted a number of 
limitations in SDP. SDP limits session descriptions to defining a session having a single set 
of timings that apply to all of the streams within it. A session in which a stream starts mid- 
way through the transmission cannot easily be described using SDP. The structure of a 
session description written in SDP must be a simple linear list of streams which may not 
reflect the intuitive structure of a complex session. SDP supports a limited and predefined 
set of applications which can receive the streams and a limited and predefined set of 
transport mechanisms (e.g. Simple layering. RTP and UDP). As guaranteed Quality of 
Service (QoS) is becoming more and more desirable to the consumer and the supplier, the 
need to define QoS policies for the entire session and individual streams in terms of 
required system resources, bandwidth requirements and supported applications also needs 
to be met. There may also be requirements onthe prioritisation of streams and subsessions 
or more complicated rules about receiving streams. A further requirement on the part of 
the supplier will be the need for charging facilities permitting the charging of an end user 
for a multicast transmission to which they subscribe according to the QoS and types of 
streams received etc. There is little scope to include information about QoS policies or 
charging within the conventional strucmre of an SDP session description, or any metadata 
about the session. 

) According to a first aspect of the present invention, a method of am^ouncing a description 
of a media session comprises the steps of generating a first base module containing user 
orientated data relating to the media session, generating at least one media module 
containing technical data necessary for a user to receive a media stream of the media 



session, .inking *e flrs. base .cdule to .he a. .east one n-edia module, a«. announcing the 
„,edia session by n..ing at .east the first base module availah.e to potential r^ipients of 

media module pennits a party to access the at .east one media module a^i subsequently 

receive the media stream. 

Preferably, the method fi^rther comprises the steps of generating a second base module, the 
second base module containing user orientated data relating to a sub-session of the media 
session, linking the second base module to the frst base module, generating at least one 
media module, and .inking said at .east one media moduie to the second base module. 

Preferab.y, the method further comprises the steps of generating an options modu.e 
containing data relating to criteria required to participate in the media session and linking 
the options module to a base module. 

According to a second aspect of the present invention, a computer readable storage 

^ Hp«:rrintion of a media session, the 

Hat^ Hprmine at least a part of a descnpuon 

meoiuiii cvjiitaxixo w«^t* «^ 

session description comprising a first base modu.e containing user orientated data relating 
ao module Which provides t^hnical data necessary for a user to receive a media stream of the 

fu^ iPa«;t one media module and subsequently 
media module permits a party to access the at least one me 

receive the media stream. 
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The present invention provides a modular description system for a media session in which 
session descriptions are constructed in a hierarchical manner providing a plurality of levels 
of information concerning the constituent parts of the described session. 

A problem faced with the current distribution of announcements from the single 
announcement group address is that there is a limit to the size of each announcement and 
the frequency with which each can be sent out. In the present invention, it is possible to 
provide a modular description system in which a distributed amiouncement contains links 
available to the end user to other portions of the amxouncement which have not been 
transmitted. 



Preferably, the media .e^ion may be armouaced by tra,«miumg all of the eonstituen. 
,„«tales of sessioa description. More preferably, the media session raay be amtounced 
,5 by trausmining only some of the constimen. modules of the session deseription, with the 
remaming modules of the session description being subsequently accessible by an 
mterest^i party using one or more links provided in the modules transmitted. The 
remainit* modules of the sessior, description may be held on one or more servers and the 
one or more links to the «maining modules may be in the form of URl pointers. Modules 
20 of the session description may contain links to modules which are generated subsequent to 
the announcement. 



Another problem 



faced by providers of current (multi)media sessions and the developers of 
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an 



me associated (m»Ui)media applications is the spread of skills required to in,.lement 
application that can initiate and manage a real-time data connection over a conununicatioi^s 
network and perform the (muUi)media functions the end user would expect. Furthermore, 
until now the only way a QoS policy could be implemented was to process a session 
5 description to determine which streams of a session could or should be run and dren to 
initialise the applications so they connect to the respective streams. This required the 
communications manager not only to know about the session requirements and available 
system resources but also the capabilities of each application. 

10 According to a mird aspect of Are present invention, a method of managing media stream 
connections for a media session, having obtained at a terminal a session description of the 
^edia session announced in accordance with the method of the firs, aspect of the preseM 
invention, comprises the steps of parsing the session description to determine associated 
multimedia client applications for the or each media module of the session description, 

1 5 passing at least a portion of the session descripUon to the or each associated multimedia 
client application, wherein the multimedia client applications are arranged to select one or 
more media streams identified by the or each media module and, having selected the one 
or more media streams, initiating the one or more media streams so that the or each media 
stream can subsequently be received by the terminal. 



20 



According to a fourd, aspect of the presem invemion, a system tor managing media stream 
connections at a terminal derived from a session description of a media session announced 



m 



accordance with the method of the first aspect of the present invention, comprises means 
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tor parsing *e session description to detennine ass^iated multnnedia c.iem applications 
(or me or each media modnle of the session description, means for passing at least a 
portion of the session description to the or each associated multimedia client applicaUon. 
wherein the multimedia client applications are arranged to select one or more appropriate 
„edia streams identified by the or each media module and, means for initiating the one or 
.edia streams so that the or each media stream can subsequently be received by the 



more 
terminal 



,„ a preferred example of the presem invention the media modules of a session description 
,0 ^ Checked by the respective multimedia dien, application prior to QoS management, 
.hereby reducing the workload of the communicatior. manager. Furthermore, applications 
only request streams from the s^sion control system since ftis is now handles 
centrally the creation and management of streams in real time. This aspect is also the 
subject of our co-pending UK patent application (Agents reference PJFI0051GB). 

15 

The presem invention simplifies application development and service provision. A further 
problem is that applications should be able to adapt to available ..twork and host 
resources. This is pariicularly important for multi-party applications operating in 
heterogeneous enviromnents where each party may have different resources available to 
20 them. Furthermore tite namre of the heteroget^ity may vary over the lifetime of the 
session, for example as network congestion varies or as the terminal resources are shared 
with other applications or oU,er users. The present invention is able to use a QoS policy 
incorporated within the session description to prioritise the allocation of resources and to 
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determine whether participation in the session is 



A still further problem is that the application developer and service provider typically need 
to address security and charging requirements. The present invention allows security and 
5 charging policies to be incorporated within the session description for use within the 
session control system to invoke appropriate charging and security procedures. Instead of 
having to develop security and charging functions the application developer and service 
provider need only specify appropriate policies. 

10 In the present invention application development is simplified by using the session 
description to drive the dynamic management of communication cham^els and to adapt to 
available resources. It also reduces the problem of handling charging and security 
requirements to a matter of specifying charging and security policies within the session 
description. 

15 

An example of the present invention will now be described in detail with reference to the 
accompanying drawings, in which: 

Figure 1 is a schematic diagram illustrating a multicast transmission across the MBone; 
Figure 2 is a schematic diagram illustrating the distribution of an SDP announcement; 
20 Figure 3 is a block diagram of a modular session description of a simple session generated 
in accordance with the present invention; 

Figure 4 is a block diagram of a modular session description of a complex session 
generated in accordance with the present invention; 
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Figure 5 is a schematic diagram of a sys«m for nunaging media sueam connections; 
Figure 6 is a flow ctar, illusrraUng *= s.ps involved in nm^ging a media session 
according to the system of Figure 5; and. 

Figure 7 is a flow chart Birther illustrating a parsing step of Figure 6. 

Figure 3 is a i,lo* diagram of a session description 300 for a simple multicast television 
session. The session description 300 comprises a base module 310 linked to a media 

module 320. 

and timing information. The base module 310 may also include a description or abstract, 
contact mformation about the organiser and a WWW or an intranet URI pointing to a web 
Site containing mrther information. Ideally, -he base module 310 should contain enough 
information for the user to decide if they are interested in participating in the session. 



•nre media module 320 conuins announcement data relating to a video stre^ of the 
session. The media module 320 contains the technical information (dau) necessary for the 
user to receive the associated media stream. In particular, connection, timing and media 
fomat details are provided. 

20 

■ inn apnerated for transmission to end users is 
A first example of a session description 300 generatea lor 

shown below: 
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( 

type = (base) 
id =(3 10) 

info = (title = "live multicast television session") 

source = (name = " A . Sender" email = asender@tx. com) 

media=(video=(client=odbitsO. 16)) 

time = (length = 50m repeat = continuous) 

category = ( " Entertainment ") 

options = (none) 

modules = (m = 320) 



( 

type = (media) 
id=(320 310) 

media =(video = (client =odbitsO . 16)) 
connection=(229. 1 . 1 .2/7000) 
time = (length = 50m) 

) 



Session description example 1 



The base module 310 has a unique identifier (id field) used in the generation of links 
between two modules during the processing of the session description. The modules field 
of the base module 310 lists the type and unique identifier of the media module 320 linked 
to the base module 310. The second identifier in the id field of the media module 320 is 
the unique identifier belonging to the base module 310 linking the media module back to 
the base module 310. By extension, these two-way links permit a module tree to be 
traversed from a base module downwards or from a media module upwards. The use of 
this feattire is described later with reference to session description example 4. 

The connection field of the media module 320 contains the IP multicast address and port 
number from which the media stream can be received. 

Figure 4 is a block diagram of a session description 400 for a complex multicast session of 
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a multimedia conference with two tracks and a panel discussion. Each track provides 
multiparty video and audio conferencing and a shared whiteboard for leaving notes and 
messages. The panel discussion is encrypted and the whole conference is subject to a 
subscription fee payable in advance by each participant. 



5 



The session description 400 contains a top level base module 410 linked to further base 
modules 420, 430, 440 and an options module 411. The top level base module 410 
contains data relating to the overall session including its name, purpose and timing 
information. The options module 411 contains details of the payment mechanism for 
10 subscription fees. 

Each further base module 420, 430, 440 relates to a subsession of the conference. Base 
module 420 relates to the first track of the conference. The base module 420 is linked to 
media modules 421-423, each containing comiection, timing and media format data for 
15 respective video, audio and whiteboard streams. 

The base module 420 is also linked to options module 424 which contains data relating to a 
QoS policy for the first track defining which media modules are optional and which are 
mandatory for a participant of the first track. The mandatory list contains identifiers of 
20 those media modules which are needed for the session or subsession to operate correctly 
whilst the optional list contains identifiers of the media modules that are not necessary for 
the session or subsession to operate correctly if system resources are scarce. 
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The base module 430 relates to the second track of the conference. It is linked to media 
modules 431^33, each containing connection, timing and media format details for 
respective video, audio and whiteboard streams. The base module 430 is also linked to 
options module 434 which contains data relating to a QoS policy for the second track 

5 defining which media modules are optional and which are mandatory for a participant of 
the second track. Base module 440 relates to the panel discussion. It is linked to media 
modules 441 and 442, each containing connection, timing and media format details for 
respective video and audio streams of the panel discussion. The base module 440 is also 
linked to options module 443 which contains encryption details (ie. how and where to get 

10 the necessary cryptographic keys) necessary for a participant to decode the panel 
discussion media streams 441, 442 according to a known encryption mechanism such as 
DES or public key encryption. 

The video media stream defined in media module 441 is layered. Layering of media 
15 streams allows users with different system resources to receive as much of the stream as 
their system resources allows. Every user must receive the bottom layer of the stream 
containing the minimum stream data. However, if a user has sufficient free system 
resources they can receive the next layer up containing enhancements to the previous layer. 
Successive layers can be received enhancing the received media stream until the maximum 
20 number of layers is received or all free system resources capacity is used. The media 
module 441 is linked to an options module 444 which contains data on the layering 
necessary for the end user to be able to receive the layered stream correctly. 



15 

The portion of the session description 400 generated for modules 410, 41 1, 420 and 440 for 
transmission to end users is shown below in session description example 2. 
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# overall conference session 

type = (base) 

id=(410) 

info = (title = "Multiraedia98 Conference") 
source = (owner = "Joe Bloggs" email = joe@nowhere.com) 
media = (video = (client = RealPlayerG2) whiteboard = (client = wb)) 
time(start= "09:00 GMT 25/12/98" stop=''13:00 GMT 25/12/98") 
options =(oc =4 11) 

modules =(b =420 b=430 b=440 oc=411) 



# conference track 1 
type = (base) 
id=(420 410) 

info = (title = "MM98 Systems and Applications Track") 
source = (owner = "Joe Bloggs" email = joe@nowhere.com) 
media = (video = (client = RealPlayerG2) whiteboard = (client = wb)) 
time(start = "09:00 GMT 25/12/98" stop="ll:00 GMT 25/12/98") 
options = (osq =424) 

modules =(m= 421 m=422 m=423 osq=424) 



# session QoS for track 1 
type= (option-sQoS) 
id = (424 420) 
mandatory =(421 422) 
optional =(423) 



§ conference panel discussion 
type = (base) 
id =(440 410) 

info=(title = "MM98 Panel Discussion") 

source = (name = "Joe Bloggs " email = joe@nowhere xom) 

media = (video = (client =RealPlayerG2) whiteboard = (client =wb)) 

time(start = "ll:00 GMT 25/12/98" stop="13:00 GMT 25/12/98") 

options = (osec =443) 

modules=(m=441 m= 442 osec =443) 



# video for panel discussion 
type = (media) 
id=(441 440) 

info = (title = "MM98 Panel Discussion Video") 
source = (owner = "Joe Bloggs" email =joe@nowhere. com) 
media = (video = (type = live client = RealPlayerG2)) 
connection=(226.0.0. 106/1010 policy =444) 
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10 



15 



20 



) 
( 

■> 

) 
( 

-> 



time=(start="ll:00 GMT 25/12/98" stop="13:00 GMT 25/12/98") 



# media QoS policy for panel discussion video 
type = (option-mQoS) 
id=(444 440) 

mechanism = (layer = (base =226.0.0. 106/1010 number=3)) 



# encryption policy for panel discussion 
type = (option-sec) 
id =(443 440) 

participant = (member = w3c) 

publickey = (location =http: //www. w3 .org/members_only/) 
info = (location = http: //www. w3 .org/) 



) 
( 



25 



# charging policy for entire conference 

type= (option-chg) 

id=(411410) 

mechanism = (type = AAA) 

price = (fee = lOOOGBP) 

info = (location=http://www.aaa.net/) 

Session description example 2 



Where there is surplus network bandwidth available, complete session descriptions can be 
announced to end users who may then elect to receive the announced session or parts 

30 thereof. However, the individual modules of the session description do not need to be 
announced together. If the network bandwidth available for announcements restricts the 
size of session descriptions, only the top level base module may be announced. In this 
simation, the link between modules may be a URI to a WWW or an intranet web site or 
server, an email address, an IP multicast address, an FTP address or details of a file or 

35 database stored on a local computer system from which an interested user can obtain the 
remaining modules. 
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The following session description example illustrates how the above session description 
base module 420 would be changed if media module 421 was stored on a WWW server: 



( # conference track 1 
type=G)ase) 
id=(420 410) 

info = (title = "MM98 Systems and Applications Track") 
source = (owner = "Joe Bloggs" email =joe@nowhere.coni) 
media = (video = (client = RealPlayerG2) whiteboard = (client = wb)) 
time(start= "09:00 GMT 25/12/98" stop="ll:00 GMT 25/12/98") 

options =(osq=424) -o-j At-, 

modules =(m=421 location=http://www.announce.org/cgi-bin/raodule.cgi?id=421 

m=421 m=423 osq=424) 

Session description example 3 



Furthermore, top level modules of a session description may be announced well in advance 
of the acmal transmission, at a time where the final details of content are unknown, in 
which case the remaining levels may be made available from pre-announced links at a later 
time. 

Figure 5 is a schematic diagram of a system for managing media stream connections at a 
terminal of an end user system according to the present invention. 

The session control system 500 is* linked to an announcement receiving interface 510 and 
one or more multicast-capable multimedia applications 520. The session control system 
500 and the announcement receiving interface 510 are connected to a network interface 
530 via which announcements may be received and multicast transmissions may be 
initiated and/or received. 
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Announcements received at the network interface 530 are routed to the receiving interface 
510. The receiving interface 510 decodes each announcement to obtain the session 
description and displays the user oriented information from the one or more base modules 
in a list to the user. The user is able to select a session description from the list announcing 
5 a session they wish to receive. The selected description is passed to the session control 
system 500 which determines which of the user's multimedia applications 520 are required 
for participation in the described session, starts the applications and initiates and provides 
the necessary media streams to the respective applications 520 via a communications 
manager 550. 

10 

The receiving interface 510 may be linked to other Internet communications applications 
540 such as a WWW browser or an email client (not shown) which may be used to gather 
further information on the described session based on links provided in the session 
description. Also, where an incomplete set of base and/or media modules of a session 
15 description are received, the receiving interface 510 attempts to obtain the remaining 
modules using the Internet communications applications prior to passing it onto the session 
control system 500. 

Figure 6 is a flow chart showing the steps taken by the session control system 500 upon 
20 receipt of a session description. The description is first parsed in step 600 to identify client 
applications for each media module. Once this is done a second parse is carried out where 
applications are launched in step 610, that is to say for each media module start the 
application specified in the client field if that application has not already been started. The 
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portion of the session description relating to the respective media type, i.e. the media 
module, the base module directly above the media module, all other modules attached to 
that base module and any other options modules that apply, is passed to the corresponding 
application in step 620. Since the media modules are marked with appropriate client 

5 applications, each application will be able to select those media streams that it wants to 
participate in. The application replies to the session control system with a connection 
request specifying its requirements in the form of a list of identifiers of media modules 
from which streams are to be initiated in step 630. The connection request is assembled by 
the session control system in step 640 and the system then parses the session description to 

10 identify other applications to launch in step 645. If a further media type is found, steps 610 
to 640 are repeated, otherwise the session control system uses the assembled connection 
requests to form a list of media modules. This list is passed, together with a session QoS 
policy, to the communications manager, a system used in by the session control system, 
which determines according to the QoS policies and available system resources whether 

15 each connection request is viable. 

The session QoS policy is constructed in two steps: 

- first, the multiple session QoS policies relevant for all the media modules to be initiated 
are combined into one session QoS policy 
20 - second, the resulting session QoS policy may be adapted to take account of (a) user 
default preferences (defined in a user profile), (b) a user's wish to determine the policy 
interactively, and (c) an application's default configuration (defined in the application 
profile(s)). 
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The communications manager responds to the session control system in step 650 with an 
indication of the viable media stream connection requests. If necessary, the session control 
system may contact a charging system to initiate accounting for the session prior to 
5 requesting the communications manager to create the viable media stream connections in 
step 660. 

Once a session starts, each received data stream relating to the session is passed to the 
associated multimedia application in step 670 until the scheduled stream time ends in step 
10 680 or the multimedia application requests to the session control system that the connection 
is terminated in step 690, at which point the session control system disconnects the 
connection in step 700. 

Figure 7 is a flow chart showing the QoS management step 650 of Figure 6 in greater 
15 detail. 

Having received the assembled list of connection requests, the communications manager 

matches each item of this list to a media profile in step 705. A media profile defines 

♦i- ■ ■ . * 

requirements which must be met for the requested media stream to operate on the end 
20 user's computer including the minimum network bandwidth needed for satisfactory 
reception of the stream. 

A terminal profile is determined in step 710. The terminal profile defines the resources 
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which are available at the end user's computer for use by the requested media streams. 
This includes available network bandwidth, free memory and disk space and available 
hardware such as monitor size, processor speed and free audio and video capture devices. 
The media profile of each connection request is compared against the available system 
5 resources defined by the terminal profile in step 720. If the termmal profile matches or 
exceeds the media profile, the connection request is declared viable in step 730 and the 
terminal profile is decremented accordingly for the remaining connection requests in step 
740. Each connection request is processed until there are no remaining requests or until the 
media profile of a request exceeds the terminal profile. In this situation, the 

10 communications manager determines the optimum terminal profile the user's computer 
would have if all non-essential applications were not running in step 750 and whether the 
computer is capable of fulfilling the media profile in step 760. If the computer is capable 
of fulfilling the media profile, the communications manager attempts to free system 
resources from currently allocated streams or connection requests which have lower 

15 priority or by asking the user to terminate other non-essential applications running on the 
computer in step 770. Alternatively, this could be done by reducing the number of layers 
received from a layered stream transmission. If sufficient resources cannot be found an 
exception is reported to the user and the connection request is marked as unviable. If the 
media stream that cannot be received is defined as mandatory in a QoS policy for a media 

20 session or subsession, all the connection requests for that media session or subsession are 
cancelled in step 790. If, however, the media stream is optional, the communications 
manager continues processing further connection requests in step 720. Once all pending 
connection requests have been processed, the communications manager reports those that 
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are viable to the session control system. 



The processing of a session description will now be described with reference to Figure 4 
and session description example 4 which is the session description generated for Track 1 
5 (modules 410 and 420-424 of Figure 4). 



10 



15 



20 



25 



30 



35 



40 



45 



) 



) 



# overall conference session 
type = (base) 
id =(4 10) 

info =(title = "Multimedia98 Conference") 
source = (owner ="106 Bloggs" email =joe@nowhere. com) 
media = (video = (client = RealPlayerG2) whiteboard = (client = wb)) 
time(start= "09:00 GMT 25/12/98" stop = "13:00 GMT 25/12/98") 
options == (oc =(X) 1 0) 

modules = (b =420 b=430 b=440 oc=411) 



# conference track 1 
type = (base) 
id = (420 410) 

info=(title = "MM98 Systems and Applications Track") 
source = (owner = "Joe Bloggs" email = joe@nowhere.com) 
media = (video = (client = RealPlayerG2) whiteboard = (client = wb)) 
time(start = "09:00 GMT 25/12/98" stop = "ll:00 GMT 25/12/98") 
options = (osq = 424) 

modules = (m =421 m=422 m=423 osq=424) 



# video for track 1 
type = (media) 
id =(421 420) 

info=(titIe = "MM98 Systems and Applications Track Video") 
source = (owner = "Joe Bloggs" email =joe@nowhere.com) 
media = (video = (type^= live client = RealPlayerG2)) 
connection^ (226.0.0". 100/1000) 

time = (start ="09:00 GMT 25/12/98" stop = "ll:00 GMT 25/12/98") 



# audio for track 1 
type = (media) 
id=(422 420) 

info = (title = "MM98 Systems and Applications Track Audio") 
source = (owner = "Joe Bloggs" email =joe@nowhere.com) 
media = (audio = (type = live format = g7 1 1 )) 
connection = (226.0.0. 101/1001) 

time = (start="09:00 GMT 25/12/98" stop = "ll:00 GMT 25/12/98") 
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( # whiteboard for track 1 
type = (media) 

► id=(423 420) 

info = (title ="MM98 Systems and Applications Track Whiteboard ) 
source=(owner="Joe Bloggs" email =joe@nowhere.com) 
media = (whiteboard = (client = wb)) 
connection=(226.0.0.102/l(X)2) 

time=(start= "09:00 GMT 25/12/98" stop="ll:00 GMT 25/12/98") 

) 

( # session QoS for track 1 
type = (option-sQoS) 

► id=(424 420) 

mandatory=(421 422) 
optional =(423) 

) 

Session description example 4 

The session control system, having received the above session description, processes the 
tree structore of the session description starting at base module 410. The first module 
encountered is base module 420. As this is not a media module but it does have sub- 
modules, the session control system continues down this branch to media module 421. 

The media field of the media module 421 already defines the multimedia client application 
required as RealPlayerG2 thus the session control system ignores it and continues to the 
next media module. The media field of the media module 422 does not have a multimedia 
cliem application defined, however a format for the audio data is specified. The session 
control system recognises that this particular audio format can be supported by 
RealPlayerG2 so it amends the media field to read client =RealPlayerG2. The next media 
module 423 has already defined a client application as wb so it ignores this module, and it 
also ignores the option module 424. 



24 

The session control system parses the tree structure again in order to launch client 
applications. The first media module 421 specifies that RealPlayerG2 should be launched, 
hence the session control system launches the application on the end user's system and 
5 keeps a record of this activity. The second media module 422 specifies an application that 
has already been launched and so the session control system ignores it and continues to the 
next media module. The media module 423 specifies that wb should be launched, so the 
session control system launches the application and keeps a record of this activity. 

10 RealPlayerG2 is passed the media module 421, base module 420 and modules 422-424. 
The application processes the media modules given to determine which it can handle, and 
in this case it identifies 421 and 422. Having determined which streams it can handle, the 
application sends a connection request back to the session control system requesting 
connection to the media streams of modules 421 and 422. Similarly, wb is passed the 

15 media module 423, base module 420, modules 421-422, and the module 424. The 
application process the given modules as described previously, and requesting connection 
to the media stream of modules 423 . 

The above connection requests are assembled by the session control system into a list, this 
20 list is then passed to the communications manager along with the session QoS policy 
module 424. The communications manager determines whether each request is viable 
according to the steps of Figure 7. 
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Assuming there are sufficient resources for all the connection requests for mandatory 
media streams, the communications manager passes back a list of viable streams to the 
session control system which then processes the tree again to determine the connection data 
held in the connection field of each media module so it can request that the 
5 communications manager initiate a connection to the appropriate media stream for each of 
the viable connection requests according to the connection data. The session control system 
then manages the session and its media stream connections as is described with reference 
to steps 670 to 700 of Figure 6. 

10 Due to the heterogeneity of the Internet and differing capabilities and operating 
environments of end user computer systems, the session control system described has been 
implemented in Java (Java is a Trade Mark of Sun Microsystems Inc.). The announcement 
receiving interface, Session Directory, receives the announcements and passes those 
selected by the end user to the session control manager implemented as an application 

15 programming interface running as a background process on the end user's computer. 

Whilst the present invention has been described with reference to the Internet and multicast 
transmissions, it will be apparent to the reader that the described modular session 
description and the session control system are applicable to the announcement and 
20 subsequent management of connections to media streams of a (multi)media session using 
other known transport mechanisms such as unicast. 

Furthermore, although mechanisms for encryption, charging and other such services have 
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not been explicitly described, it would be apparent to the reader that appropriate session 
descriptions and associated functions within the session control system for their processing 
could be readily implemented according to the mechanism required. 



CLAIMS 
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1. A method of announcing a description of a media session, comprising the steps of: 
generating a first base module containing user orientated data relating to the media session; 

5 generating at least one media module containing technical data necessary for a user to 

receive a media stream of the media session; 

linking the first base module to the at least one media module; and, 

announcing the media session by making at least the first base module available to potential 

recipients of the media session, 
10 wherein the link between the first base module and the at least one media module permits a 

party to access the at least one media module and subsequently receive the media stream. 

2. A method according to claim 1, further comprising the steps of: 

generating a second base module, the second base module containing user orientated data 
15 relating to a sub-session of the media session; 

linking the second base module to the first base module; 

generating at least one media module; and, 

linking said at least one media module to the second base module. 

20 3, A method according to claim 1 or 2, further comprising the steps of: 

generating an options module containing data relating to criteria required to participate in 

the media session; and, 

linking the options module to a base module. 
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4. A method according to claim 3, in which the data contained in the options module 
relates to a quality of service policy to be used by the media session or a part thereof. 

5. A method according to claim 3 or 4, in which the data contained in the options 
module relates to a security system to be used by the media session or a part thereof. 

6. A method according to any of claims 3 to 5, in which the data contained in the 
options module relates to a charging system to be used by the media session or a part 
thereof. 

7. A method according to any preceding claim, further comprising the steps of: 
generating a media module containing technical data necessary for a party to receive a 
layered media stream of the media session; 

linking said media module to a base module; 

generating an options module containing data relating to a layered mechanism of the 
layered media stream necessary for a party to participate in the layered media stream of the 
media session; and, 

linking the options module to said media module. 

8. A method according to any preceding claim, in which the technical data contained 
in a media module includes data necessary for a user to transmit data for inclusion in the 
media session. 
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9. A method according to any preceding claim, in which the media session is 
announced by transmitting all of the constituent modules of the session description. 

5 10. A method according to any of claims 1 to 8, in which the media session is 
announced by transmitting only some of the constituent modules of the session description, 
with the remaining modules of die session description being subsequently accessible by an 
interested party using one or more links provided in the modules transmitted. 

10 II. A method according to claim 10, in which the remaining modules of the session 
description are held on one or more servers and the one or more links to the remaining 
modules are in the form of URI pointers. 

12. A method according to any preceding claim, in which modules of the session 
15 description contain links to modules which are generated subsequent to the announcement. 

13. A computer readable storage medium containing data defining at least a part of a 
description of a media session, the session description comprising a first base module 
containing user orientated data relating to the media session, wherein the first base module 

20 includes a link to at least one media module which provides technical data necessary for a 
user to receive a media stream of the media session, and wherein the link between the first 
base module and the at least one media module permits a party to access the at least one 
media module and subsequently receive the media stream. 
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14. A computer readable storage medium according to claim 13, in which the at least 
one media module is also held on the storage medium. 

5 15. A computer readable storage medium according to claim 13, in which the link to 
the at least one media module of the session description is a pointer to a remote computer 
readable storage medium where the at least one media module is held. 

16. A computer readable storage medium according to claim 15, in which the pointer is 
10 a URI pointing to a data source on a server. 

17. A computer readable storage medium according to any of claims 13 to 16, in which 
the session description further comprises a second base module containing user orientated 
data relating to a sub-session of the media session, and at least one media module linked to 

15 the second base module, the second base module being linked to the first base module. 

18. A computer readable storage medium according to any of claims 13 to 17, in which 
the session description further comprises an options module containing data relating to 
criteria required to participate in the media session, the options module being linked to the 

20 first base module. 



19. A computer readable storage medium according to any of claims 13 to 18, in which 
the session description further comprises a media module linked to the first base module 
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containing technical data necessary for a user to receive a layered media stream of the 
media session, and an options module linked to said media module containing data relating 
to a layered mechanism of the layered media stream necessary for a user to participate in 
the layered media stream of the media session, 

5 

20. A computer readable storage medium according to any of claims 13 to 19, in which 
the link between any two modules is bi-directional. 

21. A method of managing media stream connections for a media session, having 
10 obtained at a terminal a session description of the media session announced in accordance 

with the method of any of claims 1 to 12, comprising the steps of: 

parsing the session description to determine associated media client applications for the or 
each media module of the session description; 

passing at least a portion of the session description to the or each associated multimedia 
15 client application, wherein the multimedia client applications are arranged to select one or 
more media streams identified by the or each media module; and, 

having selected the one or more media streams, initiating the one or more media streams 
so that the or each media stream can subsequently be received by the terminal. 

20 22. A method according to claim 21, in which a terminal session control system parses 
the session description and passes at least a portion of the session description to the or each 
multimedia client application. 
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23. A method according to claim 22, in which the teraiinal session control system 
passes the entire session description to the or each multimedia client application. 

24. A method according to claim 22, in. which the terminal session control system 
5 passes for each subsession of the session description, at least one media module and the 

linked base module. 

25. A method according to claim 24, in which the terminal session control system also 
passes any options modules associated with the subsession. 

26. A method according to any of claims 22 to 25, in which the or each multhnedia 
client application passes back a connection request to the terminal session control system 
with a number of identifiers of one or more media modules identifying the one or more 
media streams required by the multimedia client application. 

27. A method according to claim 26, in which the or each multimedia client application 
generates or modifies a quality of service policy for the connection requests for use by the 
terminal session control system. 

20 28. A method according to claim 25 or 26, in which the or each multimedia client 
application modifies the session description for changing the subsequent management of 
connections by the terminal session control system. 
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29. A method according to any of claims 26 to 28, in which the terminal session 
control system passes the connection requests to a communications manager which 
determines whether the connection requests are viable and subsequentiy initiates the 
connections. 

30. A method according to any of claims 26 to 29, in which the terminal session 
control system prioritises the connection requests from the multimedia client applications 
according to a quality of service policy to create a set of connection requests which are 
passed to the communications manager. 

31. A method according to claim 30, in which the quality of service policy is defined in 
the session description. 

32. A method according to any of claims 29 to 31, in which the communications 
manager determines resources required for each connection request and whether the 
requests can be met given available resources. 

33. A method according to claim 32, in which if the connection requests can be met the 

connections are initiated. 

34. A method according to claim 32, in which if a connection request cannot be met 
and the connection request is for an optional media stream of the media session then the 
communications manager proceeds by declaring the connection request unviable and moves 
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to the next connection request. 

35. A method according to claim 32, in which if a connection request cannot be met 
and the connection request is for a mandatory media stream of the media session then the 

5 communications manager proceeds by attempting to free resources to meet the connection 
request. 

36. A method according to claim 35, in which if the communications manager is unable 
to free sufficient resources to meet the connection request, the connection request is 

10 declared unviable and the communications manager refuses to join the media session. 

37. A method according to any one of claims 22 to 36, in which once a media session 
is active the terminal session control system manages the connections to the media streams 
of the media session, 

15 

38. A method according to any of claims 21 to 37, further comprising the step of 
obtaining any missing modules of the session description identified by links in the session 
description before parsing the session description, 

20 39. A system for managing media stream connections at a terminal derived from a 
session description of a media session announced in accordance with the method of any of 
claims 1 to 12, comprising: 

means for parsing the session description to determine associated media client applications 
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for the or each media module of the session description; 

means for passing at least a portion of the session description to the or each associated 
multimedia client application, wherein the multimedia client applications are arranged to 
select one or more appropriate media streams identified by the or each media module; and, 
5 means for initiating the one or more media streams so that the or each media stream can 
subsequently be received by the terminal. 

40. A system according to claim 39, in which the means for parsing the session 
description and passing at least a portion of the session description to the or each 

1 0 multimedia client application is a terminal session control system. 

41. A system acGdrding^^tb "Claim '40, in which the' tem system is 
arranged to pass thetentire sessiori^deseription^to thes^^^or^eac^h^ client application, 

15 42, A system according to claim 39, in which the terminal session control system is 
arranged to pass, for each subsession of the session description, at least one media module 
and the linked base module. 

43. A system according to claim 42, in which the terminal session control system is 
20 arranged to also pass any options modules associated with the subsession. 

44. A system according to any of claims 42 to 44, in which the or each multimedia 
client application is arranged to pass back a connection request to the terminal session 
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control system with a number of identifiers of one or more media modules identifying one 
or more media streams required by the multimedia client application. 

45. A system according to claim 44, in which the or each multimedia client application 
5 is arranged to generate or modify a quality of service policy for the connection requests for 

use by the terminal session control system. 

46. A system according to claim 44 or 45, in which the or each multimedia client 
application is arranged to modify the session description for changing the subsequent 

10 management of connections by the terminal session control system. 

47. A system according to any of claims 39 to 46, in which the means for initiating the 
connections is a communications manager. 

15 48. A system according to claim 47, in which the communications manager is arranged 
to determine whether the connection requests are viable and subsequently initiate the 
connections. 

49. A system according to any of claims 47 or 48, in which the terminal session control 
20 system is adapted to prioritise the connection requests for the one or more media streams 
from the multimedia client applications according to a quality of service policy to create a 
set of connection requests which are passed to the communications manager. 



i 
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50. A system according to claim 49, in which the quality of service policy is defined in 
the session description. 



51. A system according to claim 49 or 50, in which the communications manager is 
5 arranged to determine resources required for each connection request in sequence and 

whether the connection requests can be met given available resources. 

52. A system according to claim 51, in which the communications manager is arranged 
to initiate the connections if the connection requests can be met. 

10 

53. A system according to claim 51, in which the communications manager is arranged 
to declare a connection request unviable and to move to the next connection request if the 
connection request cannot be met and it is for an optional media stream of the media 
session. 

15 

54. A system according to claim 51, in which the communications manager is arranged 
to attempt to free resources to meet a connection request if the connection request cannot 
be met and it is for a mandatory media stream of the media session. 

20 55. A system according to claim 54, in which the communications manager is arranged 
to declare a connection request unviable and thereby refuse to join the media session if it is 
unable to free sufficient resources to meet the connection request. 
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56. A system according to any of claims 39 to 55, in which the terminal session control 
system is arranged so that once a media session is active the terminal session control 
system manages the connections to the media streams of the media session. 

57. A system according to any of claims 39 to 55, further comprising means for 
obtaining any missing modules of the session description identified by links in the session 
description. 

58. A system according to claim 57, comprising an aimouncement interface which is 
arranged to detect missing modules in a received session description and subsequently 
obtain them using the links in the session description. 

59. A computer readable storage medium containing executable instructions for 
performing the method of any of claims 21 to 38. 

60. A computer readable storage medium containing the system for managing media 
stream connections according to any of claims 39 to 58. 
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